home *** CD-ROM | disk | FTP | other *** search
/ SGI Developer Toolbox 6.1 / SGI Developer Toolbox 6.1 - Disc 4.iso / documents / RFC / rfc1412.txt < prev    next >
Text File  |  1994-08-01  |  7KB  |  229 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       K. Alagappan
  8. Request for Comments: 1412                 Digital Equipment Corporation
  9.                                                             January 1993
  10.  
  11.  
  12.                        Telnet Authentication: SPX
  13.  
  14. Status of this Memo
  15.  
  16.    This memo defines an Experimental Protocol for the Internet
  17.    community.  Discussion and suggestions for improvement are requested.
  18.    Please refer to the current edition of the "IAB Official Protocol
  19.    Standards" for the standardization state and status of this protocol.
  20.    Distribution of this memo is unlimited.
  21.  
  22. 1. Command Names and Codes
  23.  
  24.    Authentication Types
  25.  
  26.       SPX          3
  27.  
  28.    Suboption Commands
  29.  
  30.       AUTH         0
  31.       REJECT       1
  32.       ACCEPT       2
  33.  
  34. 2.  Command Meanings
  35.  
  36.    IAC SB AUTHENTICATION IS <authentication-type-pair> AUTH
  37.    <SPX authentication token> IAC SE
  38.  
  39.       This is used to pass the SPX authentication token to the remote
  40.       side of the connection.  (A document which describes the
  41.       authentication token syntax is forthcoming.)  The first octet of
  42.       the <authentication-type-pair> value is SPX.  The second octet is
  43.       a modifier to the SPX authentication type.
  44.  
  45.    IAC SB AUTHENTICATION REPLY <authentication-type-pair> ACCEPT
  46.    <mutual response> IAC SE
  47.  
  48.       This command indicates that the authentication was successful.
  49.       After an SPX authentication exchange, both sides have securely
  50.       established a random 8-byte key to be used as the default key for
  51.       the ENCRYPTION option.  If the AUTH_HOW_MUTUAL bit is set in the
  52.       second octet of the authentication-type-pair, the sender includes
  53.       the mutual response bytes.  The receiver of the ACCEPT command
  54.       compares the "mutual response" with its expected mutual response.
  55.  
  56.  
  57.  
  58. Telnet Working Group                                            [Page 1]
  59.  
  60. RFC 1412                     SPX for Telnet                 January 1993
  61.  
  62.  
  63.       (A document which describes the mutual response syntax is forth
  64.       coming.)  If the AUTH_HOW_ONE_WAY bit is set in the second octet
  65.       of the authentication-type-pair, the sender includes zero bytes of
  66.       mutual response.
  67.  
  68.    IAC SB AUTHENTICATION REPLY <authentication-type-pair> REJECT
  69.    <optional reason for rejection> IAC SE
  70.  
  71.       This command indicates that the authentication was not successful,
  72.       and if there is any more data in the sub-option, it is an ASCII
  73.       text message of the reason for the rejection.
  74.  
  75. 3.  Implementation Rules
  76.  
  77.    Every command after the first AUTHENTICATION IS must carry the same
  78.    set of modifiers (e.g., CLIENT|MUTUAL) for subsequent AUTHENTICATION
  79.    IS and AUTHENTICATION REPLY commands.
  80.  
  81.    If the second octet of the authentication-type-pair has the AUTH_WHO
  82.    bit set to AUTH_WHO_CLIENT, then the client sends the initial AUTH
  83.    command, and the server responds with either ACCEPT or REJECT.
  84.  
  85.    If the second octet of the authentication-type-pair has the AUTH_WHO
  86.    bit set to AUTH_WHO_SERVER, then the server sends the initial AUTH
  87.    command, and the client responds with either ACCEPT or REJECT.
  88.  
  89. 4.  Examples
  90.  
  91.    User "joe" may wish to log in as user "pete" on machine "foo".  If
  92.    "pete" has set things up on "foo" to allow "joe" access to his
  93.    account, then the client would send IAC SB AUTHENTICATION NAME "pete"
  94.    IAC SE IAC SB AUTHENTICATION IS SPX AUTH <joe's spx authentication
  95.    token> IAC SE.  The server would then authenticate the user as "joe"
  96.    from the token information, and the server would send back either
  97.    ACCEPT or REJECT.  If mutual authentication is being used, the server
  98.    would include in the ACCEPT message, a mutual response.  The
  99.    authorization check to see if "pete" is allowing "joe" to use his
  100.    account is made after the authentication exchange is complete.
  101.    Therefore, it is possible for the client to receive an ACCEPT
  102.    response (based on the authentication token), but for joe to be
  103.    denied access to log in to pete's account.
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Telnet Working Group                                            [Page 2]
  115.  
  116. RFC 1412                     SPX for Telnet                 January 1993
  117.  
  118.  
  119.        Client                           Server
  120.                                         IAC DO AUTHENTICATION
  121.        IAC WILL AUTHENTICATION
  122.  
  123.        [ The server is now free to request authentication information.
  124.          ]
  125.  
  126.                                         IAC SB AUTHENTICATION SEND SPX
  127.                                         CLIENT|MUTUAL SPX CLIENT|ONE_WAY
  128.                                         IAC SE
  129.  
  130.        [ The server has requested mutual SPX authentication.  If mutual
  131.          authentication is not supported, then the server is willing to
  132.          do one-way SPX authentication.  ]
  133.  
  134.        [ The client will now respond with the name of the user that it
  135.          wants to log in as, and the SPX authentication token.  ]
  136.  
  137.        IAC SB AUTHENTICATION NAME
  138.        "pete" IAC SE
  139.        IAC SB AUTHENTICATION IS SPX
  140.        CLIENT|MUTUAL AUTH <spx
  141.        authentication token
  142.        information> IAC SE
  143.  
  144.        [ The server responds with an ACCEPT command to state that the
  145.          authentication was successful.  ]
  146.  
  147.        [ If AUTH_HOW_MUTUAL, the server responds with the mutual
  148.          response so the client can verify that it is really talking to
  149.          the right server.  ]
  150.  
  151.        [ If AUTH_HOW_ONE_WAY, the server responds with a NULL mutual
  152.          response, since the client is willing to trust the server
  153.          already.  ]
  154.  
  155.                                         IAC SB AUTHENTICATION REPLY SPX
  156.                                         CLIENT|MUTUAL ACCEPT <mutual
  157.                                         response> IAC SE
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Telnet Working Group                                            [Page 3]
  171.  
  172. RFC 1412                     SPX for Telnet                 January 1993
  173.  
  174.  
  175. Security Considerations
  176.  
  177.    The ability to negotiate a common authentication mechanism between
  178.    client and server is a feature of the authentication option that
  179.    should be used with caution.  When the negotiation is performed, no
  180.    authentication has yet occurred.  Therefore, each system has no way
  181.    of knowing whether or not it is talking to the system it intends.  An
  182.    intruder could attempt to negotiate the use of an authentication
  183.    system which is either weak, or already compromised by the intruder.
  184.  
  185. Author's Address
  186.  
  187.    Kannan Alagappan
  188.    Digital Equipment Corporation
  189.    550 King Street, LKG1-2/A19
  190.    Littleton, MA 01460
  191.  
  192.    EMail: kannan@sejour.lkg.dec.com
  193.  
  194.    Mailing List: telnet-ietf@CRAY.COM
  195.  
  196.  
  197.    The working group can be contacted via the current chair:
  198.  
  199.    Steve Alexander
  200.    INTERACTIVE Systems Corporation
  201.    1901 North Naper Boulevard
  202.    Naperville, IL 60563-8895
  203.  
  204.    Phone: (708) 505-9100 x256
  205.    EMail: stevea@isc.com
  206.  
  207.  
  208.  
  209.  
  210.  
  211.  
  212.  
  213.  
  214.  
  215.  
  216.  
  217.  
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Telnet Working Group                                            [Page 4]
  227.  
  228.  
  229.